在企業級 RAG 系統中，光靠 語意檢索 常常還不夠。因為在真實業務場景下，文件不僅有「內容」，還有大量 結構化屬性（Metadata），例如：

• 文件類型：報告、簡報、法規、FAQ
• 時間：發布日期、修改時間
• 部門 / 作者：法務部、財務部、客服中心
• 權限：公開文件 / 內部文件 / VIP 客戶文件

這些元數據能成為 預過濾條件，在檢索階段就縮小範圍，大幅提升精準度。

為什麼需要元數據檢索？

1. 減少噪音

使用者問「2024 年的財報」，若沒過濾，系統可能還會返回 2019、2020 的財報。

2. 提升效率

先過濾「財務部 + 2024」，再檢索，索引範圍立刻縮小。

3. 權限控制

不同角色只能看到允許的文件，必須在檢索前就過濾。

元數據設計原則

設計 Schema 時要兼顧 檢索效率 與 業務靈活性。

1. 常見 Metadata 欄位

• ID / 文件標識：唯一索引鍵
• 類型（type）：FAQ、法規、報告
• 日期（date）：發布時間、更新時間
• 來源（source）：系統名稱、部門
• 權限（access_level）：public / internal / confidential
• 標籤（tags）：業務主題標籤
• 版本（version）：文件版本號
• 語言（language）：zh-TW、en-US

2. 設計原則

• 必要性：只保留業務檢索必需的欄位，避免冗餘
• 可擴展性：Schema 可隨業務需求動態增減
• 標準化：確保同一欄位使用一致格式（日期格式、部門命名）
• 可索引性：選擇適合建索引的數據類型和結構

Metadata 過濾機制

通常有兩種結合方式：

1. 檢索前過濾（Pre-filtering）

先用元數據過濾候選文件，再進行語意檢索。

-- 範例：先過濾再檢索
WHERE type = "法務文件" 
  AND year = 2024 
  AND access_level IN ("public", "internal")
→ Vector Search on filtered subset

優點：

• 減少向量檢索範圍，提升速度
• 節省計算資源
• 確保權限控制

2. 檢索後過濾（Post-filtering）

先用語意檢索取 Top-K，再依 Metadata 過濾。

Vector Search → Top-100 candidates
→ Filter by metadata: department = "財務"
→ Final Top-10 results

優點：

• 不會因過濾過嚴而漏掉相關文件
• 適合複雜的元數據查詢條件

企業常用「前置過濾」，因為可以直接減少 ANN 檢索範圍，效能更好。

效能優化策略

1. 索引分片（Sharding）

按 Metadata（如部門、年份）建立分片索引，減少單次檢索範圍。

索引結構：
├─ 財務部_2024/ (財務部2024年文件)
├─ 法務部_2024/ (法務部2024年文件)  
└─ 客服部_FAQ/ (客服FAQ文件)

2. 結構化索引 + 向量索引融合

• Elasticsearch 處理 Metadata 過濾
• 向量資料庫 處理語意相似度
• 兩者結果合併排序

3. 快取機制

常見過濾條件（例如「2024 財務報告」）可快取檢索結果。

4. 複合索引設計

針對常用的 Metadata 組合建立複合索引：

-- 複合索引範例
CREATE INDEX idx_dept_year_type 
ON documents (department, year, document_type)

企業應用案例

法務部門

檢索法律條文時，必須過濾「國家 / 年份 / 條文類型」。

# 法務文件檢索範例
filters = {
    "document_type": "法規",
    "country": "台灣",
    "year": {"gte": 2020},
    "status": "有效"
}

客服知識庫

不同客戶群組（VIP / 普通）使用不同 FAQ 範圍。

# 客服知識庫權限過濾
user_level = get_user_level(user_id)
filters = {
    "document_type": "FAQ",
    "access_level": {"in": ["public", user_level]}
}

研發文件檢索

依「專案代號 + 版本號」過濾，避免 LLM 拿到舊版本文件。

# 研發文件版本控制
filters = {
    "project_code": "PROJ-2024-AI",
    "version": {"gte": "v2.0"},
    "status": "latest"
}

實際效益

• 純向量檢索 Recall@10 ≈ 70–80%
• 加入 Metadata Pre-filtering 後：Recall@10 提升至 ≈ 85–90%
• 查詢延遲平均降低 20–40%（因為索引範圍縮小）
• 權限錯誤降低至接近 0%

實務注意事項

1. Metadata 品質管控

• 建立標準化的標籤體系
• 定期清理和更新元數據
• 自動化元數據提取和驗證

2. 動態權限管理

def get_accessible_filters(user_id, base_filters):
    user_permissions = get_user_permissions(user_id)
    
    # 根據用戶權限動態調整過濾條件
    if "confidential" not in user_permissions:
        base_filters["access_level"] = {"ne": "confidential"}
    
    return base_filters

3. 過濾條件平衡

避免過濾過於嚴格而漏掉相關文件，建議：

• 設定最小返回數量閾值
• 當過濾結果過少時，自動放寬條件
• 提供「擴大搜尋範圍」的選項

總結

• Metadata 是結構化的檢索助力：透過類型、時間、權限等屬性縮小範圍
• 最佳實踐：結合 Pre-filtering + Vector Search
• 企業收益：檢索更精準、更快，並保障權限安全
• 關鍵要素：良好的 Schema 設計 + 高品質的元數據維護

想想看

1. 過濾策略選擇：Pre-filtering 可能漏掉相關文件，Post-filtering 可能影響效能。如何找到最適合的平衡點？

2. 元數據演進管理：當業務需求變化時，如何平滑地更新元數據 Schema 而不影響線上服務？